Day 2 回頭整理了公司原本那套便當系統。
它不是完全不能用。
反而因為已經真的跑過一段時間，我更清楚哪些東西是必要的：
問題變成：
如果要把這套系統重新做一次，第一版到底該用什麼？
我當時沒有先決定「我要學哪個框架」。
而是先看限制。
一開始的目標很單純：
先做出一個真的有人可以用的手機版便當系統。
而且它有幾個很現實的條件。
第一，使用人數不大。
它不是公開 SaaS，也不是每天幾十萬 request 的服務，而是公司內部使用。
第二，資料量不算誇張。
本質上就是：
第三，我希望管理方式越直覺越好。
如果每次改個菜單、調個資料，都要開資料庫工具、寫 SQL、部署後端，對這種內部工具來說反而太重。
所以當時我看到 Google Sheets 的時候，第一個反應是：
這東西很像一個大家都看得懂的後台。
資料直接攤在表格裡。
要看訂單，就看 Orders。
要看使用者，就看 Users。
要改資料，也不需要另外做一套管理介面。
對第一版來說，這非常有吸引力。
如果只有 Google Sheets，當然還不夠。
讓這個組合變得實用的是 Google Apps Script，也就是 GAS。
GAS 可以直接操作 Google Sheets，也可以提供 Web App 與 API。
於是架構很快就變成：
手機瀏覽器
↓
React 前端
↓
Google Apps Script
↓
Google Sheets
Google Sheets 負責資料。
GAS 負責邏輯。
React 負責使用者看到的介面。
這個組合現在回頭看很樸素，但在當時很合理。
因為我需要的不是「最終架構」。
而是：
能不能先把真實流程搬上手機，而且真的能用。
我原本熟悉的工作環境，並不是 GAS + React 這套組合。
我的主要經驗比較偏銀行資訊系統、COBOL、AIX、PHP、JavaScript、SQL 這類型。
如果完全靠自己從零摸索，我可能會先花很多時間研究：
但有 AI 之後，開發方式變得很不一樣。
我不需要先把整套技術學完，才有資格開始做。
我可以先說：
我要做一個公司內部便當系統。
使用者用手機操作。
後端先用 Google Sheets。
需要有使用者、菜單、訂單與管理功能。
然後邊做邊問。
某個 API 不熟，就查那個 API。
某段 React 不會，就先讓 AI 幫我拆。
某個 GAS 行為有問題，就針對問題去修。
這也成了我後來持續使用 AI Agent 開發的原因之一。
它改變的不是「我不用懂程式」。
而是：
我不用等到每一項技術都學完整，才開始解決問題。
當時系統逐漸有了幾個核心區塊。
例如：
這些資料放在 Google Sheets 裡，GAS 再負責讀寫與驗證。
對使用者來說，看到的則是一個手機可以直接操作的網頁。
這和原本桌面感比較重的舊系統相比，體驗已經完全不同。
也因為 Google Sheets 本身就是表格，所以開發過程中有一個很大的優點：
資料非常容易看。
如果今天有人說：
我的訂單好像怪怪的。
我可以直接打開 Sheet 看。
如果管理者想確認某個人的資料，也可以直接查表。
在系統還小的時候，這種透明度非常方便。
現在回頭看，我反而覺得第一版最重要的價值，不是用了 GAS，也不是用了 React。
而是：
它很快把「想法」變成了「真的有人使用的系統」。
很多 side project 最後停在：
想需求
↓
選技術
↓
研究框架
↓
再研究一下
↓
沒有上線
這套便當系統沒有走這條路。
它很快就進入：
做第一版
↓
真的有人用
↓
發現問題
↓
繼續修改
而一旦真的有人開始使用，需求就不再是我自己想像出來的。
它會直接冒出來。
例如：
這些問題，都是系統「活起來」之後才開始變得重要。
Google Sheets 最大的優點，是資料很好看。
後來我才慢慢發現：
這同時也是它開始變複雜的地方。
當 Sheet 只是拿來記錄資料時，非常舒服。
但當系統開始要求：
事情就開始不只是「把資料寫進一格」這麼簡單。
原本很直覺的表格，也慢慢開始承擔後端系統才會遇到的責任。
而這也成了下一階段的問題。
這不是純概念示範，而是一套持續開發中的便當訂購系統。
文章主要寫的是「為什麼這樣演進」，實際程式碼、文件與後續變化則持續放在 GitHub。
GitHub：
https://github.com/henryfir456/bento-order-app
當資料開始不只是「放著方便看」，而是牽涉訂單、金額、歷史與多人操作時，
我才開始發現：
Google Sheets 正在承擔的責任，已經和我一開始想像的不太一樣了。
iThome鐵人賽
看影片追技術